Thanks go to

• Myhrginoc, he provide me the asm code (I didn't know anything about Ollydbg 2 weeks ago), and also made the first comments that really helped me to start.
• SVR, for having done half of the work, always beeing here when I lacked some asm knowledge, and having make some errors (that way I can say "I helped too" )

DESCRIPTION :
This function load a .DS1 (a map of the game). Extracted from D2Common v1.09b. In the v 1.09d it's at 6FD76530 (just + 00000010 than in 1.09b).

This function takes one parameter on the stack, the pointer to the ds1 file name string. It also takes parameters in ECX and EDX. ECX is an offset to the DS1_INFO structure ('this' object in C++).


STRUCTURES USED :
















LOCAL VARIABLES (on stack) :
Some are used for almost anything, so these infos won't be very usefull in fact

READ DS1 HEADER :

CONVERT DIRECTIONS / SHADOW LAYER / UNKNON LAYER :

OBJECTS :

We'll handle objects of Type 1, 2 and 4. In fact, there's no objects of type 4 in all the 2264 ds1 I have checked, so you can skip the complex part of the Type 4 objects.

Apparently, a ds1 can use the Type 2 objects of the previous acts (no check), but it can't use the ones of the further acts (there IS this check). By just removing this check any ds1 should be able to use any objects of Type 2 (like for Type 1 currently).

UNKNOWN DATA / NPC PATHS :

I must have been blind when I found the unknown layer & the unknown data between the objects & the npc paths. I just found what they're used for. The 2nd datas are X & Y position of groups in the Group Layer, and it have their Width & Height too.

Let's take an exemple : Data\Global\Tiles\Expansion\Siege\5x1barricade_brk_rules.ds1



There are 2 ways to understand the relations between the layer and the definitions.

Imagine that the user is in my ds1 editor, where it see each tiles. When moving the mouse over the tiles of that map, the program know immediatly (by checking the Tag at that Tile position) if that tile is part of a Group (if tag = 0 then not part of a group). If the Tile is part of a group, the Tag in itself is useless, because we'll check all the Groups Definition structure and compare the Tile position with the area of the groups in there. The mouse is on the Tile 1, 24. The Tag is 1F, so we're on a group. Which one ? By checking the Definition structure, we'll find that this tile fit in the area # 4 : (0, 24) ---> (4, 24). And we find another data then : the last column which is always set to 14 in that ds1, but can be another values in other ds1.

The other way to use it is by taking an area. We can then check the GROUPS layer and deduce its Tag value (problem : by this method several tags can be found for 1 area).

Now, what all these datas are used for ? Two solutions :

• either they have some meaning in the Level Editor of Blizzard, to help to select a group for instance, but are not used by the game anymore (we already have such useless datas : the file strings in the header, where some old ds1 use files with .TG1 and not .DT1 extension).
  
• Or the other solution is that these datas are still used by the game, and therefore for what ? I think of some miscelaneous gfx that appear randomly, like Trees, corpse. I have the intuition that theses datas are useless... but I need to made some tests for that.

Btw, corected an error : the Type 1 lookup table is not ACT * 75 dwords, but ACT * 60.

Whoa, excellent post! Although it's not surprising that a post like this about ds1 files comes from you

Excellent work, Paul! There is so much information here, it will probably be next year before I understand it all. I am sure the next version of your editor will be a formidable tool, even in comparison with your current version!

He he thanks . What surprised me is that, despite it was the first time I try to decode an asm listing, it was not really that difficult in fact. But I'm glad that SVR was with me on that deciphering, it really need both of us to achieve this result, after near 2 weeks of hard works.

Now that I feel a lot more confident with asm, I'll work again on something else later, who know ? But I have discovered also that's it's such a time-consumed process Hence, my congratulations goes to all our code-editing programmers here, they're great !

Edit : Btw, next year is only in 1 month

For a better understanding of the ds1 format, here's a simple DS1 format revision history, before I make a more serious Doc.

In Version 1, here's the format :

• VERSION
• WIDTH
• HEIGHT
• 1 WALL layer
• 1 FLOOR layer
• 1 ORIENTATION layer for the WALL layer
• 1 reserved layer (not used)
• 1 SHADOW layer

version 2 introduced OBJECTS
version 3 introduced FILENAMES
version 4 introduced WALL_NUM, and changed the order of layers
version 5 made some changes to the objects ID & TYPE
version 6 introduced a FLAG data to each OBJECTS
version 8 introduced ACT, and change the ORIENTATION meaning (older ds1 need convertions)
version 9 introduced a jump of 2 dwords right after the FILENAMES
version 10 introduced TAG_TYPE (but not used until version 12 ?)
version 12 use the reserved layer, it become the TAG layer
version 13 introduced an unknown dword to each GROUP
version 14 canceled the jump of 2 dwords right after the FILENAMES, and introduced NPC_PATH
version 15 introduced the ACTION data to each NPC_PATH
version 16 introduced FLOOR_NUM
version 18 introduced a jump of 1 dword at the begening of the GROUP

Now (Version 18), the format is :

• VERSION
• WIDTH
• HEIGHT
• ACT
• TAG_TYPE
• FILENAMES
• WALL_NUM
• FLOOR_NUM
• WALL_NUM (WALL + ORIENTATION) layers
• FLOOR_NUM layers of FLOOR
• 1 SHADOW layer
• optional TAG layer (only if TAG_TYPE is 1 or 2)
• OBJECTS
• optional GROUPS (only if TAG_TYPE is 1 or 2)
• NPC_PATH

Or "why my editor (and the Isilweo's one too) had problems for loading some ds1"